Present electronic devices typically use a microprocessor as a core processing element with some sort of shared interface to a number of peripheral processing elements that jointly carry out the functionality required of the device or its application. Microprocessors come in a variety of forms, but they all share a common functionality of providing a standard interface through which other devices or peripherals can be temporarily or permanently interconnected for the exchange of information. These bus interfaces come in a variety of physical and protocol related forms.
SDIO, as specified by the SD Card Association (www.sdcard.org), is one of several interface standards that are based on a master-slave configuration. SDIO is related to the bus interface used in the Secure Digital (SD) memory card that is in turn based on the Multimedia Card (MMC) format.
The Master-Slave configuration is a common bus topology, and is also used by the protocols SDBus, MMC, and USB. In the master-slave configuration, all data transfers are initiated by a master, and the slave can only respond to commands issued by a master device. Through the use of a slave device address mechanism, multiple slaves can be connected on the same bus, as shown in FIG. 1.
Slave devices commonly respond to two broad categories of commands—write commands and read commands. Whenever the master wants to carry out a ‘write’, it sends the write command followed by the data to be written. The slave latches this data and carries out the required action, such as to store the data into a specified memory location, or pass the data to an intended functional block within the device. Whenever the master wants to carry out a ‘read’, it sends a read command accompanied by an address to be read, and the slave responds by driving the appropriate data onto the bus. In a shared bus arrangement, at any time, only one master or slave device may drive the data bus. The master as initiator of the read or write operation determines when a slave device can send data to the shared bus.
There are typically two types of slave devices in the SD family: devices with fast memory and devices with slow IO. For a fast memory type of slave device, the device master will simply provide write data accompanied by an address, or a read data address, and the response time of the device is not a concern. For slower memory devices, the data may be posted for writing at the convenience of the device, or the read operation may complete in a relatively short window of time that will not tie up the processor during the interval required for the data to be recovered and provided. A slow slave IO operation may invoke a significantly longer process, such as a read or write to a remote device across a network which may not be reachable at the time the transaction occurs, or the request for data from a device providing GPS data which includes an acquisition latency interval, or any other IO operation which has a long or unknown latency time. Because of the ability to bridge across several SDIO devices, the latency problem occurs particularly in SDIO devices which may be used as an interface through which complex functions can be provided on a separate device. These functionalities include wireless data access through WLAN, or reception of navigation data through GPS, or reception of a video stream via a DVB-H receiver. These applications involve reception of data from a network wirelessly, or preparation of data through complex processing based on some inputs from the host. When a new set of data, or a packet of data, is available to be transferred to the host, the slave has to notify this condition to the master. One of the prior art methods of notifying an event to a requesting master device is to have the master poll some address location in the slave device periodically to check if any event is pending or completed. But this method has the following disadvantages:
1) The master has to poll even when there is no event pending.
2) If polling rate is kept low to reduce the overhead on the master, events will be pending for a longer time which might not be acceptable to all slaves or the applications they provide.
Another way to communicate an event is for the slave to assert an interrupt to the host or master. This can be done either through a dedicated interface pin which can be connected to one of the interrupt sources of a processor, or through a time multiplexed input on an existing interface pin, which is a method supported by the SDIO protocol.
Interrupts asserted by a slave are routed through to an appropriate software segment in the host for processing. FIG. 2 shows the various software layers involved in a general master-slave bus topology. This architecture is suggested by various standards like SDIO and USB to ease client driver development although it is burdened with excessive overhead. The Host Controller Driver provides hardware abstraction layer functionality and is responsible for interacting with the actual host controller hardware. The Bus Controller provides a cleanly abstracted view of the client device to the client drivers and is responsible for loading the corresponding client driver when a card is detected.
FIG. 3 shows the propagation of an interrupt from the SDIO slave device 310 to the processor in the master platform via SDIO slave device driver 302. FIG. 3 also shows that a series of software processes involved in a slave asserting an interrupt 312 and the master or host processor returning to service it 302. This response latency has an impact on how quickly data can be moved from an SDIO device into the host. When a packet pending interrupt 312 is detected, the host issues a read packet command and reads the corresponding packet, following which it clears the interrupt. The sequence of events is:
1) An interrupt is asserted by the SDIO slave device 310.
2) The interrupt propagates to the device driver 302 through the master controller driver 306 and bus controller driver 304, as shown in FIG. 3.
3) For a read interrupt, the length descriptor of the pending packet is read. A read interrupt is an interrupt generated to indicate a pending packet. A slave can generate an interrupt for other reasons also, and action is taken in the host appropriately.
4) The device driver issues a packet read command to the SDIO stack (the bus controller 304 and host slave device driver 302) with the length value from step 3.
5) After the packet is read, the device driver 302 issues a write command to clear the interrupt.
6) The device driver then checks whether any further packets are pending. After the interrupt is cleared, the interrupt is immediately reasserted by the slave device if there are further packets pending. The read interrupt only indicates that one or more packets are available to be read out—it does not indicate the exact number of packets available at the time the interrupt was raised. The interrupt status is checked within the interrupt service routine (ISR) so that if further packets are available, they may be handled immediately, rather than after the ISR exits and re-enters.
7) If any further packets are pending, the handler repeats steps 3 to 6, otherwise it exits from the interrupt service routine (ISR).
The following table quantifies the delays involved in the above steps for the case of four packets which are pending in the slave device:
Delay inNo.Step Causing LatencyuS1.Interrupt latency to the device90driver2.First packet length descriptor40read latency3.First packet read latency of the325SDIO stack4.Interrupt clearing latency205.Further interrupt checking20latency6.Second packet length descriptor40read latency7.Second packet read latency of325SDIO stack8.Interrupt clearing latency209.Further interrupt checking20latency10.Third packet length descriptor40read latency11.Third packet read latency of325SDIO stack12.Interrupt clearing latency2013.Further interrupt checking20latency14.Fourth packet length descriptor40read latency15.Fourth packet read latency of325SDIO stack16.Interrupt clearing latency2017.Further interrupt checking20latencyTotal1710
The stacked nature of the SDIO interrupt device drivers provides flexibility, but with an intrinsic inefficiency which results in long response latencies. Because of this inefficiency, the actual read throughput achievable is far less than the theoretical limit of bus throughput.
It is desired to increase SDIO bus throughput. Additionally, it is desired to decrease packet interrupt response latency.